---
title: "Модуль l2-load-balancer"
---

{% alert level="warning" %}
Модуль **экспериментальный** и находится в процессе активного развития. Функциональность и API могут существенно измениться.
{% endalert %}

Модуль реализует улучшенный (относительно стандартного [режима L2 в MetalLB](../../modules/380-metallb/#режим-layer-2)) механизм балансировки для сервисов в кластерах bare metal, где нет возможности воспользоваться облачным балансировщиком или [MetalLB](../../modules/380-metallb/#режим-bgp) в режиме BGP с настроенным Equal-cost multi-path (ECMP).

Основан на решении [MetalLB](https://metallb.universe.tf/).

## Принцип работы в сравнении с режимом L2 модуля MetalLB

[MetalLB в режиме L2](../../modules/380-metallb/#режим-layer-2) позволяет заказать _Service_ с типом `LoadBalancer`, работа которого основана на том, что в пиринговой сети узлы-балансировщики имитируют ARP-ответы от "публичного" IP. Данный режим имеет существенное ограничение — единовременно лишь один балансировочный узел обрабатывает весь входящий трафик данного сервиса. Соответственно:

* Узел, выбранный в качестве лидера для "публичного" IP-адреса, становится "узким местом" без возможности горизонтального масштабирования.
* В случае выхода узла-балансировщика из строя, все текущие соединения будут оборваны для переключения на новый узел, который будет назначен лидером.

<div data-presentation="../../presentations/381-l2-load-balancer/basics_metallb_ru.pdf"></div>
<!--- Source: https://docs.google.com/presentation/d/1cs1uKeX53DB973EMtLFcc8UQ8BFCW6FY2vmEWua1tu8/ --->

Данный модуль помогает обойти эти ограничения. Он предоставляет новый интерфейс _L2LoadBalancer_, который:

* Позволяет автоматически заказать несколько _Service_ с типом `LoadBalancer` по количеству узлов-балансировщиков.
* Обеспечивает равномерное распределение L2-лидерства между узлами-балансировщиками.

<div data-presentation="../../presentations/381-l2-load-balancer/basics_l2loadbalancer_ru.pdf"></div>
<!--- Source: https://docs.google.com/presentation/d/1mDfYi2E2tUni5ReQbXvA9CAZBsHXSGynArw9YB6VGvM/ --->

Таким образом:
* Прикложение получит не один, а несколько (по количеству узлов-балансировщиков) "публичных" IP. Данные IP потребуется прописать в качестве A-записей для публичного домена приложения. Для последующего горизонтального масштабирования потребуется добавить дополнительные узлы-балансировщики, соответствующие _Service_ будут созданы автоматически, потребуется лишь добавить их в список A-записей прикладного домена.
* При выходе из строя одного из узлов-балансировщиков, лишь часть трафика будет подвержена обрыву для переключения на здоровый узел.
